In enterprise information systems (EIS), application servers often connect to the EIS through a ‘connector.’ The most prevalently used connector and standards are based on JAVA™ and the connector architecture is JAVA™ Connector Architecture (JCA). Prior to the implementation of JCA, it was extremely difficult for application servers to integrate into an EIS because they had to be customized each way. The advent of JCA solved some of these problems, but created others, so integration remains difficult even with JCA.
The implementation of JCA allows JCA-enabled application servers to integrate with any JCA-compliant EIS. Beyond the standard architecture, users could still add additional functionality and/or optimizations. Users can write more specific JCA-based connectors and allow this customization to function.
One area in which the JCA has not solved problems is with regard to transaction managers. Transaction managers are parts of an application that coordinate transactions across resources. Transaction managers focus on the execution of a particular transaction across different resources. For example, if a user places an order to an online retailer, the transaction may include interactions with a catalog, order processing, inventory, shipping, etc. The transaction manager tracks all of these interactions until the transaction is complete.
These interactions involve messages between computers, typically transmitted and received between multiple application servers that may be of many different types, such as OracleWebLogic, Oracle Glassfish, Redhat JBoss, IBM Websphere, etc. The current JCA-enabled connectors do not interact well with the transaction managers with regard to messaging without extensive customization. Further, the transaction managers do not handle clustering of resources well in the messaging contexts. Clustering allows for distributed processing of the messages across multiple message servers and application servers. However, application servers typically do not have the capability to recognize foreign clusters to manage the message lifecycle and provide guarantees as to the processing of the requests in the messages. For example, IBM Websphere, IBM's application server offering, is able to deal with Websphere MQ through proprietary means since they are implemented by the same company and know the internals and are able to make agreements within the company to get things to work together. However, IBM Websphere does not know how to deal with clustered Oracle WebLogic JMS or clustered Tibco EMS JMS, which IBM does not implement and does not know the internal workings of these other products.